home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Oct 89 / Z0078-Re MacApp & InsideO-Oct89 < prev    next >
Encoding:
Text File  |  1989-10-16  |  7.0 KB  |  133 lines  |  [TEXT/GEOL]
  1. Item    6238540                         13-Oct-89        18:58
  2.  
  3. From:   ALGER                           Alger, Jeff,VCA
  4.  
  5. To:     D4684                           Robins Analytics, S Robins,PRT
  6.         MADA.EUROPE                     MacApp Dev Assoc Europe, E Carrasco
  7.         AU0008                          Kopfwerk EDV SW Entwicklung
  8.         D2086                           Efficient Field Svc, C Faith,PRT
  9.  
  10. cc:     MACAPP.TECH$                    MACAPP Tech
  11.  
  12. Sub:    Re: MacApp & InsideOut (long)
  13.  
  14. Doug, Eric, Tommi, Curtis,
  15.  
  16. Regarding MacApp and InsideOut - I have used this combination now in three
  17. projects with varying degrees of success.  Allow me to propose a slightly
  18. different slant on the solutions proposed so far to this integration.
  19.  
  20. My article in the September issue of Frameworks on "TDocument and Databases"
  21. provides an outline of the architecture, based on classical notions of
  22. relational database theory: scheme, relation, domain, and tuple.  The article
  23. was generic, not InsideOut-specific, but the techniques actually derive in part
  24. from my experience with InsideOut.  I will summarize the principal points here:
  25.  
  26. (1) The abstraction of the database consists of classes TRelation, TDomain,
  27. TAccessMethod, and TTuple.  The scheme itself is encapsulated in two instances
  28. (actually, subclasses) of TRelation: TRelationRelation, which describes all
  29. relations in the scheme; and TDomainRelation, which describes all domains in
  30. the scheme.  For this reason, no explicit class is needed to represent the
  31. scheme, just something - TDatabase - which contains references to the RR and DR
  32. relations.  A TAccessMethod maps to an index over an InsideOut "view" (which is
  33. conceptually a file of records.)  A TTuple maps to a specific record in a view.
  34.  
  35. (2) Each TRelation contains a name (string), a TList of TTuples (more about
  36. this later) and a TList of TAccessMethods.  A TRelation maps to a specific view
  37. (IO term, not MacApp) of the underlying database.
  38.  
  39. (3) Records are retrieved and queries specified using the class TCursor.  The
  40. steps to follow are these:
  41.     (a) Ask TDatabase to get you the right TRelation instance.
  42.     (b) Ask the TRelation instance to give you a fresh TCursor.
  43.     (c) Build the query in the TCursor (see below).
  44.     (d) Tell the TCursor to "bind" itself.  It, in turn, asks the
  45.         TRelation to attach sufficient information to the TCursor to
  46.         support first-next iteration over the records which match the
  47.         query.
  48.     (e) Retrieve the TTuples which constitute the answer to the query
  49.         by calling TCursor.Next repeatedly until it says "I have no more
  50.         tuples."
  51.     (f) Steps (d) and (e) can be combined in the method TCursor.Each if
  52.         appropriate.
  53.  
  54. (4) The TRelation decides on a strategy for answering the query by "offering"
  55. the TCursor at the time of binding to each TAccessMethod attached to the
  56. TRelation until one of them "accepts" it.  A TAccessMethod accepts a cursor
  57. if the query contains constraints against indexed fields of the view; i.e., can
  58. use the query to shortcut iteration over all records in the database.  If no
  59. access method accepts, an "exhaustive" access method is used to iterate over
  60. the entire view.
  61.  
  62. (5) TTuples are data structures which are capable of returning or setting the
  63. value of any domain of the relation in that tuple.  This is best done by using
  64. a variant record or a pointer to the data, since data types can vary from one
  65. domain to the next.  It would be nice to represent each individual value as an
  66. object, but in most realistic applications that results in too many records and
  67. a severe garbage collection problem.  TTuple.Flush takes any changes made to
  68. values in the TTuple and writes them out to the corresponding record in the
  69. database.
  70.  
  71. (6) TTuples are cached.  This can either be done by making the TList of TTuples
  72. in the TRelation a TSortedList.  When a query is posed which involves a unique
  73. index, the TSortedList is searched first (by the relevant TAccessMethod) for a
  74. TTuple with the right value; if it is there, no read from disk is performed and
  75. that TTuple is returned.  If not, the read takes place and the resulting TTuple
  76. is placed in the TSortedList.  If the query involves a non-unique index, a read
  77. from the view is always performed, but a new TTuple is constructed only if a
  78. matching one (according to some other, unique, index) is found in the
  79. TSortedList - otherwise, the one already cached is returned.
  80.  
  81. (7) TTuples are garbage collected by maintaining a reference counter.
  82. TTuple.Grab increments the counter, TTuple.Release decrements it.  If the count
  83. goes to zero as the result of TTuple.Release, the owning
  84. TRelation.ReleaseTuple(SELF) is called by the TTuple.  If the TRelation is
  85. caching TTuples, the TTuple is freed and removed from the cache.  If the
  86. TRelation contains all of its records in its TTuple list (i.e., caches
  87. everything or is not an InsideOut relation,) TRelation.ReleaseTuple does
  88. nothing.  If you have functions returning a TTuple as value, it is also useful
  89. to have TTuple.ReleaseButDontFree, which will not scrap the TTuple before the
  90. caller has a chance to Grab it.
  91.  
  92. This is a LOT of effort, but pays tremendous dividends:
  93.  
  94. - In my most recent project, we had a single database which had relations
  95. derived from InsideOut, maintained in memory, derived from Finder flat files,
  96. and resident on a remote host; all were represented in a single scheme with the
  97. differences between these forms invisible to the application.  (The key:
  98. subclass TRelation and TTuple wisely.)  Put another way, this architecture
  99. makes InsideOut a special case.
  100.  
  101. - The application need not be overly concerned with indexes.  They are used
  102. wherever possible automatically.
  103.  
  104. - It is possible to build on top of this structure to make the whole thing
  105. relationally complete; i.e., equivalent to SQL in expressive power.  Joins, set
  106. difference, etc., are a matter of building smarter TCursors or TRelation
  107. subclasses ("Mr. Database, give me a TRelation which represents a Join of these
  108. two relations.")
  109.  
  110. - One class - TTuple - represents all possible record types.  Normally, one
  111. must construct a separate Pascal Record type for each InsideOut view.
  112.  
  113. - Caching is automatic and better tailored to true performance gains than
  114. InsideOut's lower level block-oriented scheme.  In particular, records which
  115. are referred to repeatedly but over long periods of time are retrieved faster
  116. using this architecture than by relying on InsideOut's optimizations.  All you
  117. have to do is Grab it up front and not Release it until shutdown.
  118.  
  119. It may seem that this is a lot of overhead to carry, but my experience has
  120. shown that not to be the case, either in terms of performance or code size.
  121. What you lose on the back end you more than make up for in the front in
  122. simplicity of the interface.
  123.  
  124. Obviously, this link is already WAAAY too long and, thus, I will not go into
  125. more details.  Suffice it to say that this architecture has been implemented
  126. and works well.  If there is enough interest in the subject, I can follow up
  127. with a more in-depth article in Frameworks.
  128.  
  129. Regards,
  130. Jeff Alger
  131. KPMG Peat Marwick
  132.  
  133.